The old board code for the TS419 assigns MPP pins 15 and 16 as SATA
activity signals (and none as SATA presence signals). Currently the
device tree assigns the SoC's default pinmux groups for SATA, which
conflict with the second Ethernet port.
Reported-by: gmbh@gazeta.pl Tested-by: gmbh@gazeta.pl
References: https://bugs.debian.org/855017 Cc: stable@vger.kernel.org # 3.15+ Fixes: 934b524b3f49 ("ARM: Kirkwood: Add DT description of QNAP 419") Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/arm
Gbp-Pq: Name arm-dts-kirkwood-fix-sata-pinmux-ing-for-ts419.patch
Too many people come complaining about losing their data -- and indeed,
there's no warning outside a wiki and the mailing list tribal knowledge.
Message severity chosen for consistency with XFS -- "alert" makes dmesg
produce nice red background which should get the point across.
Signed-off-by: Adam Borowski <kilobyte@angband.pl>
[bwh: Also add_taint() so this is flagged in bug reports]
[2023-01-10: still accurate according to btrfs-progs own manpage:
https://git.kernel.org/pub/scm/linux/kernel/git/kdave/btrfs-progs.git/commit/?id=922797e15590b836e377d6dc47b828356cafc2a9]
[2024-03-17: still accurate; manpage is now in Documentation/btrfs-man5.rst
implementation went from disk-io.c to super.c; forwarded the issue]
Gbp-Pq: Topic debian
Gbp-Pq: Name btrfs-warn-about-raid5-6-being-experimental-at-mount.patch
Ben Hutchings [Wed, 13 Jul 2016 00:37:22 +0000 (01:37 +0100)]
fanotify: Taint on use of FANOTIFY_ACCESS_PERMISSIONS
Forwarded: not-needed
Various free and proprietary AV products use this feature and users
apparently want it. But punting access checks to userland seems like
an easy way to deadlock the system, and there will be nothing we can
do about that. So warn and taint the kernel if this feature is
actually used.
Gbp-Pq: Topic debian
Gbp-Pq: Name fanotify-taint-on-use-of-fanotify_access_permissions.patch
Ben Hutchings [Sat, 18 Mar 2017 20:47:58 +0000 (20:47 +0000)]
fjes: Disable auto-loading
Bug-Debian: https://bugs.debian.org/853976
Forwarded: no
fjes matches a generic ACPI device ID, and relies on its probe
function to distinguish whether that really corresponds to a supported
device. Very few system will need the driver and it wastes memory on
all the other systems where the same device ID appears, so disable
auto-loading.
Gbp-Pq: Topic debian
Gbp-Pq: Name fjes-disable-autoload.patch
Ben Hutchings [Sat, 20 Apr 2013 14:52:02 +0000 (15:52 +0100)]
viafb: Autoload on OLPC XO 1.5 only
Bug-Debian: https://bugs.debian.org/705788
Forwarded: no
It appears that viafb won't work automatically on all the boards for
which it has a PCI device ID match. Currently, it is blacklisted by
udev along with most other framebuffer drivers, so this doesn't matter
much.
However, this driver is required for console support on the XO 1.5.
We need to allow it to be autoloaded on this model only, and then
un-blacklist it in udev.
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name viafb-autoload-on-olpc-xo1.5-only.patch
There are two drivers claiming the platform:pcspkr device:
- pcspkr creates an input(!) device that can only beep
- snd-pcsp creates an equivalent input device plus a PCM device that can
play barely recognisable renditions of sampled sound
snd-pcsp is blacklisted by the alsa-base package, but not everyone
installs that. On PCs where no sound is wanted at all, both drivers
will still be loaded and one or other will complain that it couldn't
claim the relevant I/O range.
In case anyone finds snd-pcsp useful, we continue to build it. But
remove the alias, to ensure it's not loaded where it's not wanted.
Gbp-Pq: Topic debian
Gbp-Pq: Name snd-pcsp-disable-autoload.patch
There is still laptop firmware that touches the integrated GPU behind
the operating system's back, and doesn't say so in the RMRR table.
Enabling the IOMMU for all devices causes breakage.
Replace CONFIG_INTEL_IOMMU_DEFAULT_ON with a 3-way choice
corresponding to "on", "off", and "on,intgpu_off".
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic features/x86
Gbp-Pq: Name intel-iommu-add-kconfig-option-to-exclude-igpu-by-default.patch
There is still laptop firmware that touches the integrated GPU behind
the operating system's back, and doesn't say so in the RMRR table.
Enabling the IOMMU for all devices causes breakage, but turning it off
for all graphics devices seems like a major weakness.
Add an option, intel_iommu=intgpu_off, to exclude only integrated GPUs
from remapping. This is a narrower exclusion than igfx_off: it only
affects Intel devices on the root bus. Devices attached through an
external port (Thunderbolt or ExpressCard) won't be on the root bus.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic features/x86
Gbp-Pq: Name intel-iommu-add-option-to-exclude-integrated-gpu-only.patch
When kernel.perf_event_open is set to 3 (or greater), disallow all
access to performance events by users without CAP_SYS_ADMIN.
Add a Kconfig symbol CONFIG_SECURITY_PERF_EVENTS_RESTRICT that
makes this value the default.
This is based on a similar feature in grsecurity
(CONFIG_GRKERNSEC_PERF_HARDEN). This version doesn't include making
the variable read-only. It also allows enabling further restriction
at run-time regardless of whether the default is changed.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic features/all
Gbp-Pq: Name security-perf-allow-further-restriction-of-perf_event_open.patch
add sysctl to disallow unprivileged CLONE_NEWUSER by default
This is a short-term patch. Unprivileged use of CLONE_NEWUSER
is certainly an intended feature of user namespaces. However
for at least saucy we want to make sure that, if any security
issues are found, we have a fail-safe.
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
[bwh: Remove unneeded binary sysctl bits]
[bwh: Keep this sysctl, but change the default to enabled]
Gbp-Pq: Topic debian
Gbp-Pq: Name add-sysctl-to-disallow-unprivileged-CLONE_NEWUSER-by-default.patch
Ben Hutchings [Sun, 4 Aug 2019 23:29:11 +0000 (00:29 +0100)]
hamradio: Disable auto-loading as mitigation against local exploits
Forwarded: not-needed
We can mitigate the effect of vulnerabilities in obscure protocols by
preventing unprivileged users from loading the modules, so that they
are only exploitable on systems where the administrator has chosen to
load the protocol.
The 'ham' radio protocols (ax25, netrom, rose) are not actively
maintained or widely used. Therefore disable auto-loading.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic debian
Gbp-Pq: Name hamradio-disable-auto-loading-as-mitigation-against-local-exploits.patch
Ben Hutchings [Fri, 19 Nov 2010 02:12:48 +0000 (02:12 +0000)]
[PATCH 1/3] rds: Disable auto-loading as mitigation against local exploits
Forwarded: not-needed
Recent review has revealed several bugs in obscure protocol
implementations that can be exploited by local users for denial of
service or privilege escalation. We can mitigate the effect of any
remaining vulnerabilities in such protocols by preventing unprivileged
users from loading the modules, so that they are only exploitable on
systems where the administrator has chosen to load the protocol.
The 'rds' protocol is one such protocol that has been found to be
vulnerable, and which was not present in the 'lenny' kernel.
Therefore disable auto-loading.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic debian
Gbp-Pq: Name rds-Disable-auto-loading-as-mitigation-against-local.patch
Ben Hutchings [Fri, 19 Nov 2010 02:12:48 +0000 (02:12 +0000)]
[PATCH 2/3] af_802154: Disable auto-loading as mitigation against local exploits
Forwarded: not-needed
Recent review has revealed several bugs in obscure protocol
implementations that can be exploited by local users for denial of
service or privilege escalation. We can mitigate the effect of any
remaining vulnerabilities in such protocols by preventing unprivileged
users from loading the modules, so that they are only exploitable on
systems where the administrator has chosen to load the protocol.
The 'af_802154' (IEEE 802.15.4) protocol is not widely used, was
not present in the 'lenny' kernel, and seems to receive only sporadic
maintenance. Therefore disable auto-loading.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic debian
Gbp-Pq: Name af_802154-Disable-auto-loading-as-mitigation-against.patch
radeon requires firmware/microcode for the GPU in all chips, but for
newer chips (apparently R600 'Evergreen' onward) it also expects
firmware for the memory controller and other sub-blocks.
radeon attempts to gracefully fall back and disable some features if
the firmware is not available, but becomes unstable - the framebuffer
and/or system memory may be corrupted, or the display may stay black.
Therefore, perform a basic check for the existence of
/lib/firmware/radeon when a device is probed, and abort if it
is missing, except for the pre-R600 case.
Update 2023-11-08:
In bug 1053764 Mario Limonciello <mario.limonciello@amd.com> states
that the patch isn't needed anymore for amdgpu, so remove that part
of the patch
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name radeon-amdgpu-firmware-is-required-for-drm-and-kms-on-r600-onward.patch
Ben Hutchings [Thu, 30 May 2024 12:14:32 +0000 (13:14 +0100)]
firmware_loader: Log direct loading failures as info for d-i
Forwarded: not-needed
On an installed Debian system, firmware packages will normally be
installed automatically based on a mapping of device IDs to firmware.
Within the Debian installer this has not yet happened and we need a
way to detect missing firmware.
Although many/most drivers log firmware loading failures, they do so
using many different formats. This adds a single log message to the
firmware loader, which the installer's hw-detect package will look
for. The log level is set to "info" because some failures are
expected and we do not want to confuse users with bogus error messages
(like in bug #966218).
NOTE: The log message format must not be changed without coordinating
this with the check-missing-firmware.sh in hw-detect.
Gbp-Pq: Topic debian
Gbp-Pq: Name firmware_loader-log-direct-loading-failures-as-info-for-d-i.patch
The iwlwifi driver currently supports firmware API versions 4-6 for
these devices. It will request the file for the latest supported
version and then fall back to earlier versions. However, the latest
version that has actually been released is 4, so we expect the
requests for versions 6 and then 5 to fail.
The installer appears to report any failed request, and it is probably
not easy to detect that this particular failure is harmless. So stop
requesting the unreleased firmware.
Gbp-Pq: Topic debian
Gbp-Pq: Name iwlwifi-do-not-request-unreleased-firmware.patch
Ben Hutchings [Mon, 24 Aug 2009 22:19:58 +0000 (23:19 +0100)]
af9005: Use request_firmware() to load register init script
Forwarded: no
Read the register init script from the Windows driver. This is sick
but should avoid the potential copyright infringement in distributing
a version of the script which is directly derived from the driver.
Gbp-Pq: Topic features/all
Gbp-Pq: Name drivers-media-dvb-usb-af9005-request_firmware.patch
Ben Hutchings [Sat, 13 May 2023 11:03:26 +0000 (13:03 +0200)]
fixdep: Allow overriding HOSTCC and HOSTLD
Forwarded: not-needed
objtool always uses HOSTCC, HOSTLD, and HOSTAR, so we need to override
these on the command line for cross-builds of linux-kbuild. But it
also builds fixdep which still needs to be native in a cross-build.
Add support for REALHOSTCC and REALHOSTLD variables which, if set,
override HOSTCC and HOSTLD for fixdep only.
Gbp-Pq: Topic debian
Gbp-Pq: Name fixdep-allow-overriding-hostcc-and-hostld.patch
The top-level Makefile warns if the compiler version string changes at
all between the kernel build and an out-of-tree module build.
We expect that major compiler version changes could introduce ABI
changes, and override the CC variable in out-of-tree module builds to
ensure that the same major compiler version is used. But minor
version changes should not make a difference, so this exact version
comparison produces false warnings.
Since custom kernel packages don't have that, don't remove the version
comparison. Instead, skip it if $(DEBIAN_KERNEL_NO_CC_VERSION_CHECK)
is non-empty.
Gbp-Pq: Topic debian
Gbp-Pq: Name makefile-make-compiler-version-comparison-optional.patch
DKMS and module-assistant both build OOT modules as root. If they
build an old OOT module that still use SUBDIRS this causes Kbuild
to try building a full kernel, which obviously fails but not before
deleting files from the installed headers package.
To avoid such mishaps, detect this situation and abort the build.
The error message is based on that used in commit 0126be38d988
"kbuild: announce removal of SUBDIRS if used".
Gbp-Pq: Topic debian
Gbp-Pq: Name kbuild-abort-build-if-subdirs-used.patch
The module.lds linker script is now built under the scripts directory,
where previously it was under arch/$(SRCARCH).
However, we package the scripts directory as linux-kbuild, which is
meant to be able to do support native and cross-builds. That means it
shouldn't contain files for a specific target architecture without a
wrapper to select between them, and it doesn't appear that linker
scripts are powerful enough to implement such a wrapper.
Building module.lds in a different location would require relatively
large changes. Moving it in the package build rules can work, but we
need to support custom kernel builds from the same source so we can't
assume it's moved.
Therefore, we move module.lds under the arch build directory in
rules.real and change Makefile.modfinal to look for it in both places.
Gbp-Pq: Topic debian
Gbp-Pq: Name kbuild-look-for-module.lds-under-arch-directory-too.patch
Ben Hutchings [Tue, 8 Jul 2025 11:30:55 +0000 (13:30 +0200)]
android: Enable building binder as module
Bug-Debian: https://bugs.debian.org/901492
We want to enable use of the Android binder driver to support
Waydroid, but it should not be built-in as that would waste resources
and increase security attack surface on systems that don't need it.
- Change the Makefiles to build the driver as an object with the
"_linux" suffix (which is what Waydroid expects)
- Change config symbol types to tristate
- Add a module description, because modpost warns about missing
descriptions
Gbp-Pq: Topic debian
Gbp-Pq: Name android-enable-building-binder-as-module.patch
Ben Hutchings [Tue, 8 Jul 2025 11:32:21 +0000 (13:32 +0200)]
Export symbols needed by binder
Bug-Debian: https://bugs.debian.org/901492
We want to enable use of the Android binder driver to support
Waydroid, but it should not be built-in as that would waste resources
and increase security attack surface on systems that don't need it.
Export the currently un-exported symbols it depends on.
Gbp-Pq: Topic debian
Gbp-Pq: Name export-symbols-needed-by-binder.patch
YunQiang Su [Mon, 16 Nov 2020 01:11:00 +0000 (09:11 +0800)]
Use RELAXED ieee754 mode for Loongson-3 as 3A 4000 is 2008-only
Forwarded: not-needed
There are 2 mode of value of IEEE NaN hardcoded by CPU.
Currently, our mipsel/mips64el port is in so-called lagacy mode.
Loongson 3A 4000 is set as the so-called 2008 mode.
To make Debian workable on Loongson 3A 4000, we need set the kerenl in
RELAXED mode.
Ben Hutchings [Tue, 12 May 2015 18:29:22 +0000 (19:29 +0100)]
Make mkcompile_h accept an alternate timestamp string
Forwarded: not-needed
We want to include the Debian version in the utsname::version string
instead of a full timestamp string. However, we still need to provide
a standard timestamp string for gen_initramfs_list.sh to make the
kernel image reproducible.
Make mkcompile_h use $KBUILD_BUILD_VERSION_TIMESTAMP in preference to
$KBUILD_BUILD_TIMESTAMP.
Gbp-Pq: Topic debian
Gbp-Pq: Name uname-version-timestamp.patch
Ben Hutchings [Sat, 2 Jun 2012 18:53:38 +0000 (19:53 +0100)]
video: Remove nvidiafb and rivafb
Bug-Debian: https://bugs.debian.org/383481
Forwarded: no
These drivers contain register programming code provided by the
hardware vendor that appears to have been deliberately obfuscated.
This is arguably not the preferred form for modification.
These drivers are also largely redundant with nouveau. The RIVA 128
(NV3) is not supported by nouveau but is about 15 years old and
probably discontinued 10 years ago.
Gbp-Pq: Topic debian/dfsg
Gbp-Pq: Name video-remove-nvidiafb-and-rivafb.patch
* apparmor: validate DFA start states are in bounds in unpack_pdb
* apparmor: fix memory leak in verify_header
* apparmor: replace recursive profile removal with iterative approach
* apparmor: fix: limit the number of levels of policy namespaces
* apparmor: fix side-effect bug in match_char() macro usage
* apparmor: fix missing bounds check on DEFAULT table in verify_dfa()
* apparmor: Fix double free of ns_name in aa_replace_profiles()
* apparmor: fix unprivileged local user can do privileged policy management
* apparmor: fix differential encoding verification
* apparmor: fix race on rawdata dereference
* apparmor: fix race between freeing data and fs accessing it